[heos] Have to disable twice to actually disable a Bridge Thing

[Chiuaua79]

I have a Shelly that removes power from my entertainment devices (TV, soundbar (Denon), DVD player, set top box, etc.) during nights and when nobody is at home to save on electricity. I can control my soundbar via the Heos binding, primarily for selecting a TuneIn radio station under the "Favorites" channel of a Heos Player Thing.

Two-and-a-half weeks ago I upgraded openHab from 4.3.10 to 5.2.0, this all went well, but also at that moment the problem started that when selecting a radio station in the morning via openHAB did nothing. No music would play. The player Thing would show a "Broken pipe" error, the bridge looked fine. So, as a workaround, tried to disable the bridge when removing power and enable it again when restoring power. However, it appears I have to click "disable" twice to actually disable the bridge Thing. Similar from a DSL rule, when sending the API a disable command, the bridge Thing does not actually disable, but only switches to status "UNINITIALIZED".

Expected Behavior

When disabling a bridge Thing, only one action should be required to actually disable it, not two actions (pressing disable, exiting the Thing, selecting the Thing again in UI and then pressing disable again).

Current Behavior

TRACE log:

2026-08-17 07:08:50.778 [DEBUG] [nternal.handler.HeosThingBaseHandler] - Disposing this: org.openhab.binding.heos.internal.handler.HeosPlayerHandler@3ac733d6
2026-08-17 07:08:50.779 [DEBUG] [s.internal.handler.HeosBridgeHandler] - Disposing child handler for: Denon550_HEOS.
2026-08-17 07:08:50.804 [DEBUG] [s.internal.handler.HeosBridgeHandler] - HEOS bridge removed from change notifications
2026-08-17 07:08:50.804 [DEBUG] [s.internal.handler.HeosBridgeHandler] - Dispose bridge 'null'
2026-08-17 07:08:50.804 [DEBUG] [binding.heos.internal.api.HeosSystem] - Shutting down HEOS Heart Beat
2026-08-17 07:08:50.804 [DEBUG] [s.internal.resources.HeosSendCommand] - Stopping HEOS event line listener
2026-08-17 07:08:50.804 [DEBUG] [nding.heos.internal.resources.Telnet] - Stopping input listener
2026-08-17 07:08:50.805 [TRACE] [nding.heos.internal.resources.Telnet] - Sending command: heos://system/register_for_change_events?enable=off

2026-08-17 07:08:50.820 [DEBUG] [ing.heos.internal.action.HeosActions] - bundle org.openhab.binding.heos:5.2.0 (278)[org.openhab.binding.heos.internal.action.HeosActions(387)] : ServiceFactory.ungetService()
2026-08-17 07:08:50.821 [DEBUG] [ing.heos.internal.action.HeosActions] - bundle org.openhab.binding.heos:5.2.0 (278)[org.openhab.binding.heos.internal.action.HeosActions(387)] : DependencyManager: osgi.ds.satisfying.condition close component unbinding from org.apache.felix.scr.impl.manager.ComponentContextImpl@4f8b0efc at tracking count 1 refpairs: [[RefPair: ref: [{org.osgi.service.condition.Condition}={service.id=6, service.bundleid=0, service.scope=singleton, service.pid=0.org.osgi.service.condition.ConditionImpl, osgi.condition.id=true}] service: [null]]]
2026-08-17 07:08:50.822 [TRACE] [ing.heos.internal.action.HeosActions] - bundle org.openhab.binding.heos:5.2.0 (278)[org.openhab.binding.heos.internal.action.HeosActions(387)] : Querying state active
2026-08-17 07:08:50.822 [DEBUG] [ing.heos.internal.action.HeosActions] - bundle org.openhab.binding.heos:5.2.0 (278)[org.openhab.binding.heos.internal.action.HeosActions(387)] : Changed state from active to satisfied
2026-08-17 07:08:50.831 [DEBUG] [ing.heos.internal.HeosHandlerFactory] - Unregister discovery service for HEOS player and HEOS groups by bridge 'woonkamer'

Likely the lines at 07:08:50.822 makes openHab believe that it is still not disabled.

Possible Solution

unknown

Steps to Reproduce (for Bugs)

See above

Context

Disabling and later enabling the bridge Thing again, will reinitiate the Player Thing attached to the bridge as well and solves the "broken pipe" of the player Thing. Simple disabling/enabling the player Thing (this can actually be done the normal way with one click for disabling) does not solve the broken pipe.

Your Environment

OH 5.2.0
Heos binding 5.2.0
Raspberry pi4, 4GB
Raspberry pi OS trixie
Temurin Java 21.0.12

[jlaur]

I can reproduce this on my 5.2.1 system, but I don't currently have a 5.1 system to compare with. This seems unexpected, and I'm wondering if this is a core bug. I wasn't able to reproduce it with other Things, and this is (to my knowledge) outside the control of the binding, so should be consistently handled by the framework (unlike for example the potential two-step process of removing a Thing, if the binding doesn't update status to REMOVED by itself).

I noticed one thing worth investigating in the binding:

openhab-addons/bundles/org.openhab.binding.heos/src/main/java/org/openhab/binding/heos/internal/handler/HeosBridgeHandler.java

Lines 282 to 300 in b70217b

	@Override
	public synchronized void childHandlerDisposed(ThingHandler childHandler, Thing childThing) {
	logger.debug("Disposing child handler for: {}.", childThing.getUID().getId());
	if (bridgeHandlerDisposalOngoing) {
	// Checks if bridgeHandler is going to disposed (by stopping the binding or
	// openHAB for example) and prevents it from being updated which stops the
	// disposal process.
	return;
	} else if (childHandler instanceof HeosPlayerHandler) {
	String channelIdentifier = "P" + childThing.getUID().getId();
	updateThingChannels(channelManager.removeSingleChannel(channelIdentifier));
	} else if (childHandler instanceof HeosGroupHandler groupHandler) {
	String channelIdentifier = "G" + childThing.getUID().getId();
	updateThingChannels(channelManager.removeSingleChannel(channelIdentifier));
	// removes the handler from the groupMemberMap that handler is no longer called
	// if group is getting online
	removeGroupHandlerInformation(groupHandler);
	}
	}

This method is synchronized and it might trigger callback through:

openhab-addons/bundles/org.openhab.binding.heos/src/main/java/org/openhab/binding/heos/internal/handler/HeosBridgeHandler.java

Lines 424 to 428 in b70217b

	private synchronized void updateThingChannels(List<Channel> channelList) {
	ThingBuilder thingBuilder = editThing();
	thingBuilder.withChannels(channelList);
	updateThing(thingBuilder.build());
	}

BaseThingHandler locks on this in multiple places (synchronized (this) { }). I'm wondering if we somewhere can run into a deadlock.

While digging around, I found a small change in ThingManagerImpl. I don't suspect anything wrong there, but maybe @lolodomo has some knowledge from this area or ideas what to further check/look for?

[jlaur]

BaseThingHandler locks on this in multiple places (synchronized (this) { }). I'm wondering if we somewhere can run into a deadlock.

I tried to remove synchronized from those two methods just for verifying the lock theory, and it didn't change anything.

[Chiuaua79]

To be clear: I consider the need to "disbale twice" a bug. It might have been in 4.3 or it might not. Will try to test it this weekend on an old VM with 4.3 that I still have on my desktop machine.

The "broken pipe" was not present in 4.3, but I consider that more of a result of the way Heos behaves when external factors (cutting power from physical player) mislead the binding, so not a real bug, just a binding that not knows how to recover an unexpected external event. Otherwise I would have added the trace log for that as well.

Thanks for at least having a look into the disabling misbehavior.