The Thermostat That Wouldn’t Stop Asking
The Symptom
A routine sysadmin review flagged the UniFi log file at 404MB. That’s not inherently alarming for a busy network, but the growth rate was: 160MB per day. At that pace, the log would hit a gigabyte in under a week.
The easy fix would be aggressive log rotation. Set up daily rotation with size limits, maybe filter out some noise, move on. The log would stay manageable.
But that would be treating the symptom, not the disease. 160MB/day of logs means something is happening 160MB/day worth of times. What?
The Investigation
I started with log composition analysis. What was actually in that 404MB?
# Break down log by message type
awk '{print $6}' /var/log/unifi/unifi.log | sort | uniq -c | sort -rn | head -20
The result: 87% mDNS traffic. Multicast DNS queries and responses dominated the log. That’s not normal. mDNS exists for device discovery - it shouldn’t be generating hundreds of megabytes of traffic.
Drilling deeper into the mDNS entries revealed a pattern. One device was responsible for the majority: the Ecobee thermostat at 192.168.4.67 on the IoT VLAN.
66,000 Unanswered Questions
The Ecobee was sending mDNS queries at a rate of about 22 per minute. That’s a query every 2.7 seconds, continuously. And every single query had zero responses.
192.168.4.67 → _d2d._tcp.local. (no response)
192.168.4.67 → _d2d._tcp.local. (no response)
192.168.4.67 → _d2d._tcp.local. (no response)
...
_d2d._tcp.local. is Apple’s Device-to-Device service - part of the HomeKit ecosystem. The Ecobee was looking for HomeKit devices to talk to. It wasn’t finding any. And it kept asking.
Over 24 hours, that’s 31,680 queries. The log showed 66,000+ accumulated queries with zero responses. The thermostat had been doing this for days.
The Orphan Pairing
I checked the Ecobee’s settings. Under the HomeKit menu, it showed “Connected to HomeKit.”
I checked Apple Home on my phone. No Ecobee listed.
I checked Home Assistant. The Ecobee integration was present, but it was using the HomeKit Controller method - which means HA was talking to the Ecobee directly via HomeKit protocol, not through Apple’s ecosystem.
The problem: At some point, the Ecobee had been paired with Apple Home, then removed from Apple Home without being properly unpaired on the device itself. The Ecobee still thought it had a HomeKit home to report to. It was broadcasting mDNS queries looking for a HomeKit hub that no longer existed.
An orphan pairing. The device was shouting into the void, waiting for an answer that would never come.
The Fix (Not What You’d Think)
The fix wasn’t log rotation. It wasn’t filtering mDNS traffic. It wasn’t even a configuration change I could make remotely.
The fix was:
- Factory reset the Ecobee to clear the orphan HomeKit state
- Re-pair it with Home Assistant using the HomeKit Device integration
- Explicitly NOT add it to Apple Home (that creates the cross-ecosystem confusion)
After the factory reset and re-pairing, mDNS traffic from the Ecobee dropped to normal discovery levels. The log growth rate dropped proportionally.
The Router’s Role
One other discovery during this investigation: the UniFi router was responsible for about 50% of the mDNS traffic in the log.
That’s not a bug - it’s a feature. UniFi has mDNS relay functionality to allow HomeKit devices on different VLANs to discover each other. The router receives mDNS broadcasts on one VLAN and relays them to others.
The Ecobee was on the IoT VLAN. Its mDNS queries were being relayed by the router to the main VLAN. Every unanswered query generated two log entries: one for the original query, one for the relay. The router was faithfully amplifying the thermostat’s confusion.
Why Not Just Filter?
I could have added an rsyslog filter to drop mDNS entries. Problem “solved” in five minutes:
# Don't do this
if $msg contains 'mDNS' then stop
But then I’d never have found the orphan pairing. The Ecobee would still be broadcasting 22 queries per minute. The network would still be carrying that traffic. The thermostat’s battery (it has a battery for power outages) would drain faster from the constant radio activity.
More importantly, I’d lose visibility into a category of events that might indicate real problems in the future. What if a device starts an mDNS storm because of a firmware bug? I want to see that, not filter it away.
The log rotation I did implement was reasonable: daily rotation with size limits, keeping 4 weeks of history. But that’s managing healthy log growth, not hiding a problem.
Lessons
1. Investigate before you filter. Log volume spikes mean something is happening. Find out what before you decide to ignore it.
2. HomeKit orphan pairings are silent failures. The device shows “connected” but the hub doesn’t list it. There’s no error - just endless unanswered queries.
3. mDNS relay amplifies problems. If you have cross-VLAN mDNS relay enabled, a chatty device on one VLAN affects logging for all VLANs.
4. Factory reset is sometimes the right answer. You can’t always debug smart home device state remotely. Sometimes you have to wipe it and start fresh.
5. The symptom and the cause are often in different places. The symptom was a huge log file on the router. The cause was a thermostat with confused HomeKit state. Following the data led from one to the other.
The Numbers After
Before: 160MB/day log growth, 87% mDNS After: ~15MB/day log growth, mDNS at normal discovery levels
The 404MB log got rotated. The new logs stay reasonable. And I know why.
This post documents a real debugging session from January 2026. The thermostat is now properly paired and no longer asking questions nobody can answer.
Written with Claude.