Changes to the mDNS system recently? Very slow response to lookup hubitat.local

Was there a change to the mDNS system in the hubitat lately? Recently I have been suffering a minimum response time of around 5 seconds whenever issuing a MakerAPI command. Today I sat down to try to work it out and discovered after several hours of debugging that the actual request was taking at least 5 seconds from the hubitat. I could easily duplicate this with a curl command turning on or off a light. Sometimes it would take as much as 10 seconds to do so. Adding more specific timing output it became obvious that it was the dns lookup of hubitat.local that was causing the problem and replacing it with a DHCP reservation or static IP address solved the problem and it now responds and executes the command almost instantly just like it always did before. 0.005s instead of 5.832s from curl.

While testing I restarted the hubitat itself several times, I reduced it’s database size and forced it to do a database trim via the commands in the thread about the database size problems with speed. I did a shutdown and then a reboot with a long power out period in between as also recommended in that thread. I restarted my router as well as the machines I was testing from. None of it made any difference. The problem is definitely somewhere in it’s response to the lookup of hubitat.local.

Just offering thoughts - when I use "hubitat.local" in my browser, I too get slowed response. I do all reference to my unit via URL as 'hubitat'. I am running my own DNS under Windows Server 2012 and my ...
UPDATE: I checked and the 'hubitat.local' is NOT in my local DNS' any more. I know it used to be! like you I can't explain the .local (honestly, I have no idea where it came from either as it wasn't a dynamic registration per my logs).

  • I am running static
  • I have reservation in my DHCP server (also on my Windows Server)
  • My local hosts file has no reference doing override.
  • The delay reproduces on all my workstations and in multiple browsers (FF, Edge, Chrome)

It's coming from the "m" in mDNS.

@james8 - Did you have a device on your local subnet that was running Avahi or Bonjour that is no longer present?????

I have dozens of devices and computers and hubs and arduino esp32 based devices and 5 or 6 raspberry pi's and phones, tablets and probably others that all advertise Avahi, Bonjour or mDNS or whatever we call it into the .local domain. I routinely take them up and down as I build things and move them around but I’ve never noticed that could cause other issues. I do notice that it can be buggy at times. Some of my Pi’s seem to stop advertising after some amount of time and the .local address stops resolving entirely. But I’ve never seen anything like the delay in looking up hubitat.local.
My understanding of how Avahi works may be incomplete, but I didn’t think it necessarily had to talk to the device to get the address every time. I thought it was a kind of broadcast in response to a query, and then just keep sending out the keep alive packets with the information at reasonable intervals to keep all the other devices on the network up to date on the presence and address of it. I can’t make that make any sense of the very pronounced delay in resolving it. Perhaps it is trying to arp the hubitat or something and when it fails it just drops back to the cached entry? My browser seems to be caching the IP and works fine after the first connection to it, but using curl in the command line, which cannot cache it since it’s individual processes, shows the delay very clearly. It does not do this for any other device I talk to with a .local address, only the hubitat.
I had tried to set a static IP with the new features for that, but I couldn’t get it to actually stick, it saved the address in the edit field but never actually stopped using the DHCP address. Is it possible mine is in some weird state between the two settings?
My problem is that I can’t imagine how I would delay that resolution even on purpose since it should just be cached locally but I have verified this on several machines and OS’s after rebooting the hub and the computers so it’s definitely real.

Actually, as I further explore this this morning it does not seem to affect any of the raspberry pi’s. I thought I had tested that yesterday and saw it but not this morning. It may be something about how the mDNS is implemented on the Mac? Though this all worked perfectly up until a week or so ago or possibly less. On my mac when I ping the hubitat.local address it finishes it’s lookup instantly, but any other process such as curl takes 5+ seconds before it gets an IP address. It just gets weirder and weirder. It does not do it for any other device on the network that I can find. I’ve just done a curl call to 4 different raspberry pi’s and 5 other esp32 based devices and they all resolve instantly. It is only the hubitat that is doing it. I remain baffled.

1 Like

What router do you have?

1 Like

Not to sound like Microsoft tech support, but have you tried rebooting your Mac recently? I just tried ping, Opera web browser, and curl to hubitat.local from my Macbook Pro, and all resolved within 1-2 seconds.....

I wonder if the recent Mac security updates had any impact with this..

jkp: The router is a linksys “Velop” system which is running the latest firmware from them and that hasn’t changed since it started doing this.

vreihen and erktrk: I get the same result from 2 different macs on the network here, one of which is my development machine which has all the security updates, and one another test box that I have not run any updates on in the last few months at least since long before this changed.

If I do a ping from the macs it knows the IP address and starts pinging instantly. Curl is having a problem, and also my app which connects via the python requests library shows the same issue. To get detailed output on the timing of various parts of the process from curl I used this script:


curl -w @- -o /dev/null -s "$@" <<'EOF'
time_namelookup: %{time_namelookup}\n
time_connect: %{time_connect}\n
time_appconnect: %{time_appconnect}\n
time_pretransfer: %{time_pretransfer}\n
time_redirect: %{time_redirect}\n
time_starttransfer: %{time_starttransfer}\n
time_total: %{time_total}\n

When I run it on either of my 3 test macs here I get really long timings for the resolution like this:

./curltime.bash "http://hubitat.local/"
time_namelookup: 5.072900
time_connect: 5.073906
time_appconnect: 0.000000
time_pretransfer: 5.073959
time_redirect: 0.000000
time_starttransfer: 5.557005
time_total: 5.608930

when I run it with the IP address instead the output looks like this:

./curltime.bash "http://192.168.0.whatever/"
time_namelookup: 0.053673
time_connect: 0.054804
time_appconnect: 0.000000
time_pretransfer: 0.054854
time_redirect: 0.000000
time_starttransfer: 0.531687

And I get a similar timing if I run the same script from a raspberry pi here. So it’s definitely something in the implementation of the local lookup on the Mac but even there it doesn’t affect everything. I have restarted both macs and the router while trying to narrow this down and none of that made any difference that I could tell.

It has not always been this way though. I developed the interface and ran it for a year without any delay in this at all using the hubitat.local address. Then in the last couple of weeks or even more recently I started to see significant delays in anything that was controlled from the software. I would walk out to the garage and it would take 10 seconds or more to turn on the lights for me sometimes. I did a lot of other debugging before I figured out this was the problem. I’ve told my users to setup either a DHCP reservation or try to use the static IP address stuff on the hubitat that is available now and use the IP address instead and that has solved everyones problems, but not everyone is having the problem so I don’t know exactly when it happened or what accompanied it as far as software updates but something definitely changed and it wasn’t the latest security update from Apple as it does it on my machine that hasn’t had that installed yet.

If anyone can think of anything else I can do to gather more info let me know and I will! I would be happy to just blame the Mac’s failure to cache the lookups or something if it hadn’t worked perfectly for so long and then broken without a clear correlation to a software update or something.

Well, what version of MacOS are you running? The update from MacOS 11.5 to 11.6 was on September 13, 2021. That seems to correlate with when your issues started.

As a part of that update, curl was updated on the Mac. From the release notes:


These machines are both still running 10.14 Mojave and my curl version claims to be from 2019. I have no idea what problems were introduced by newer updates :wink: This also affects the python3 requests library which does not use curl on the backend.

output from my curl version:
curl -V

curl 7.64.1 (x86_64-apple-darwin18.2.0) libcurl/7.64.1 OpenSSL/1.0.2s zlib/1.2.11 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.1.1)

Release-Date: 2019-03-27

Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp

Features: AsynchDNS HTTPS-proxy IDN IPv6 Largefile libz NTLM NTLM_WB PSL SSL TLS-SRP UnixSockets

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.