Why the garage speakers kept cutting out
The gym speakers in my garage started stuttering through Spotify on a Saturday, and I knew the feeling before I knew the cause. In my experience, Ubiquiti network gear and Sonos speakers have a long, rocky history of poor interoperability and finger-pointing between their support teams. A renovation not long ago put new access points throughout the house, and in the calm that followed I had forgotten the days when my speakers were among the most sensitive clients on the network.
When people ask how I use AI in my homelab, the syslog integration is easily the driest thing I can describe, and I’ve gotten used to watching eyes glaze over partway through. This was the best argument for it I’ve had, the time for my nerdy obsession with logs to shine. My network has been logging every client’s behavior since the day it joined, and my AI tooling can read those logs, plus the controller’s settings through a read-only account. It pulled the misbehaving speaker’s history, what it did in the seconds before the audio broke up, and an hourly pattern of it falling off the network at predictable times. I read the evidence and made the changes myself.
The first finding was roaming. One speaker had sat on the garage access point for ten and a half days at an ideal signal. Then it left, briefly came back, and settled on a farther access point with a weaker signal and busier airtime, which is not the move of a device chasing the strongest signal.
I have a background in network engineering, so this was a forensic exploration rather than a crisis, a who-done-it of access point settings. Two early clues pointed the wrong way. The controller’s friendly name for the client belonged to a different speaker, and a log line that reads like an authentication rejection was really a fifteen-second timer noticing that a device had walked away mid-handshake.
What I did about the roaming was take the choice away. The two speakers that never move are now locked to the access point nearest them. I also changed a channel, which bought nothing measurable, and trimmed the transmit power on a neighboring access point, which turned a solar gateway that had been stable for days into one that switched access points as many as 27 times a day. I put that power setting back.
The lock fixed the roaming. It didn’t stop the hourly drops, and those took longer. Going back through a week of logs, every one of the 28 drops lined up with the network rotating a shared encryption key: once an hour the access point sent the speaker the new key, the exchange failed four times, and the access point disconnected it. A Mac on the same network failed the same way, so this was not only a Sonos problem. The drops stopped on their own on the afternoon of September 27, before I changed anything else, and I still don’t know what changed that day. Three days later I turned the hourly key rotation off anyway, so there is no longer an hourly exchange for the speaker to fail.
It has held a single connection since that afternoon, on the access point it’s locked to. Turns out, my fancy log system gave me a lot of data, but not all of it was actionable, and the most actionable part still couldn’t tell me why the drops stopped. For now, the drama is behind us and both device families are stable.