Repository navigation
sonos: fix offline grouped speakers - #3245
Merged
Merged
Conversation
|
Channel deleted. |
Test Results 73 files 541 suites 0s ⏱️ Results for commit 5703703. |
NoahCornell
requested review from
cjswedes,
ctowns,
hcarter-775,
kianooshkarami,
tandres,
varzac and
z-michel
September 22, 2026 22:29
tandres
approved these changes
Sep 23, 2026
hcarter-775
approved these changes
Sep 23, 2026
ctowns
approved these changes
Sep 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Check all that apply
Type of Change
Checklist
Description of Change
Fixes a bug where a Sonos speaker in a group can get permanently stuck showing Offline in the SmartThings app after a network hiccup, even though its websocket connection is actually healthy and the driver continues receiving/emitting playback events for it. Recovery previously required a full driver restart.
Root Cause
SonosConnectionuses an internal_initializedflag to track whether a connection has completed a full, successfulstart()cycle. Theon_closehandler correctly calleddevice:offline()when a socket dropped, but never reset_initializedback tofalse.Because
self_running()factored_initializedinto its own connectivity check, a connection could end up with_initializedstucktruefrom before the drop. If the other side of the relationship (the coordinator's socket, in a member's case) happened to reconnect independently before this connection's own reconnect loop got around to checking,is_running()could readtrueon its very first check — beforestart()had ever been called even once. Since the reconnect loop iswhile not is_running() do start() ... end, this meant the loop could exit without ever callingstart(), sodevice:online()was never called and the device stayed marked offline indefinitely, while still passing through capability events via a group-relay mechanism unrelated to its own health state.Fix
drivers/SmartThings/sonos/src/api/sonos_connection.lua:on_closenow resetsself._initialized = falsebefore marking the device offline, in addition to the existingdevice:offline()call.self_running()no longer factors in_initialized— it's now a pure connectivity check (Router.is_connected(unique_key)).is_running()now explicitly requiresself._initialized, alongsideself_running()andcoordinator_running().is_running()'s debug output (coordinator = self_running→coordinator = coord_running), which had been printing the same value under both labels and made this bug harder to diagnose from logs.Since
_initializedcan now only ever becometrueinside a successfulstart()call, and is guaranteed to startfalseafter any real close, the reconnect loop's "exit without ever callingstart()" path is now unreachable —is_running()cannot readtrueexcept at the exact pointstart()itself completes successfully.Summary of Completed Tests
Reproduced the original bug and validated the fix against a live 2-speaker group on a physical hub, using
iptablesto selectively drop the coordinator's connection and inspecting driver logs (OnClose,is_runningdebug output, reconnect task behavior) to confirm the device now correctly reachesdevice:online()instead of stalling.Testing Logs
Coordinator marked offline
Non-coordinator marked offline
Non-coordinator task re-connecting both coordinator and non-coordinator websockets
Coordinator set to online even though the websocket is already connected