Heos (Denon) support

@airbone42 / @CalPolyME I have a test-jar for you if you like:


You should be able to remove the other binding and then add this to your addons folder as a drop-in replacement. It only fixes the overwriting of group-membership.

It does not change functionality with regards to the master of a group. @airbone42 it would be great if you could check whether the answer of @Wire82 helps for your use-case.

@Wire82 would I break a use-case of you by making two groups distinct if they have a different master?

Two other suggestion from my side are :

1 to create a rule-action for groups, which would just call set_group with some member ids in a specific order.
2 to allow duplicate groups with the same hash to co-exist respecting the order of members, the only draw-back is they will then all be marked ONLINE.

Would one (especially the last one) work for both @Wire82 and @airbone42?

I cannot get the binding to work when I drop it in the addons folder. Are there any configuration settings I need to change or enable to get bindings in the addons folder to work?

No :frowning:

See also: https://www.openhab.org/docs/configuration/addons.html#through-manually-provided-add-ons

You could validate that you successfully removed the old binding using the karaf console, see the first part of https://www.openhab.org/docs/configuration/addons.html#through-configuration-files

@martinvw First of all thanks a lot for your continuous effort in building this. Actually it wouldn’t solve all my issues. The latest issue that I discovered is that I also couldn’t find a way to just remove one device from a group. If I switch of a group it’s totally ungrouped, but there are several cases when I just want to remove one device.

Credits for who it deserves, @Wire82 did all of the work on the initial binding.

I mainly did technical refactorings and some small improvements

I would expect that you could do that by turning the smaller group on?

IE, group a,b,c is ON

then force grouping of the group a,b

Right that could work, I was still thinking in the old way it was handled that the smaller group is already turned on due to the fact that it’s speakers are part of the bigger group. My fault :slight_smile:

I was able to get the missing dependancies installed via the console, and I can confirm that the test-jar does fix the group-membership overwriting issue. Thank you for providing it. It does appear that groups are now mutually exclusive, even if they have the same GID. This is very helpful for my case. Thank you for the support.

1 Like

As I perform more testing, I notice that although I define a group as (1,2,3), where 1 is the master, when I turn the group on in PaperUI, it does not always honor 1 as the master. Now I’m getting (3,2,1). This is counter to what @Wire82 described in his earlier post.

How does the OFFLINE detection work? I have multiple Denon HEOS devices at home and they are randomly marked ONLINE or OFFLINE - regardless of their actual state.

Specifically: I have a HEOS 7 setup as the HEOS Bridge. Through it, I have multiple players and groups available. One of them is a HEOS 3, which is currently listed as OFFLINE - although the Denon HEOS app on my smartphone lists it and I am even able to play music on it. Additionally, I am able to ping the device’s IP address. So from my point of view, this Thing as online and available as it gets.

Unfortunately it is still displayed as OFFLINE in OpenHAB. I have checked the IP address and serial number listed under the properties and they match my actual HEOS player. Besides the β€œhave you tried turning it off and on again?”-approach, I haven’t tried much.

Oddly, my Inbox shows 3 new things, which have been discovered: My group of 2 HEOS 1 players and the corresponding players in that group - although I have already added them as a Thing. It does list the player which is shown as OFFLINE as ignored - if I add it, it is added with a lengthy ID (which is hexadecimal instead of decimal), and still shown as OFFLINE

Could you enable logging for org.openhab.binding.heos and give some information like which openHAB which binding version etc.

Do you have one HEOS bridge or multiple? Can you control the player from the OFFLINE thing and does that status give any complications? Can you compare (screenshot?) the details properties of the discovered but the previously ignored thing and the thing which appears OFFLINE?

Is there any way to send the play state stop to a heos device? I detected that when using tune-in to listen to some radio a β€œpause” is simply ignored (probably as it’s not possible to pause a stream, but only stop it). Unfortunately, the default openhab player has only play and pause, but no stop.

I tried it already by sending direct Heos CLI commands to the speaker, it works when I set the play state to stop instead of pause.

Is there any plan to offer something like that? Otherwise I would bypass the binding in this case with some custom solution.

The problem is that the framework does not support the concept STOP on controls.

The HEOS app also does some fancy things there, they do mention that in API documentation on page 7.

So in some cases, they use stop and in others they use pause. We could implement the same behaviour, following their example.

Edit: I have some initial setup to get the information, however, I did not yet switch my branch to the right repo :slight_smile:

Yes that was the idea to use in the binding internally stop/pause depending on the heos-scenario, while obviously it also has to be a pause in openhab, as they don’t support more.

Looking forward to the binding-update to test it :slight_smile:

What version are you running currently? Did you already upgrade to 3.x?

No still on 2.5.9. Too much stuff I’m experimenting with right now, so didn’t want to open another construction yard yet :wink:

I’m not at home so I cannot test it myself, but this might work :wink:



just tested it and it seems to work, thanks a lot.


Anyone else seeing these warnings after upgrading to OH3?

2021-01-12 11:56:33.857 [WARN ] [fig.discovery.DiscoveryResultBuilder] - Representation property 'serialNumber' of discovery result for thing 'heos:player:dcbc810e-ea46-16cb-0080-0005cd51ce40:1827671404' is missing in properties map. It has to be fixed by the bindings developer.
        at java.base/java.lang.Thread.getStackTrace(Thread.java:1607)
        at org.openhab.core.config.discovery.DiscoveryResultBuilder$1.run(DiscoveryResultBuilder.java:181)
        at org.openhab.core.config.discovery.DiscoveryResultBuilder$1.run(DiscoveryResultBuilder.java:1)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at org.openhab.core.config.discovery.DiscoveryResultBuilder.getStackTrace(DiscoveryResultBuilder.java:178)
        at org.openhab.core.config.discovery.DiscoveryResultBuilder.build(DiscoveryResultBuilder.java:157)
        at org.openhab.binding.heos.internal.discovery.HeosPlayerDiscovery.handleDiscoveredPlayers(HeosPlayerDiscovery.java:117)
        at org.openhab.binding.heos.internal.discovery.HeosPlayerDiscovery.scanForPlayers(HeosPlayerDiscovery.java:98)
        at org.openhab.binding.heos.internal.discovery.HeosPlayerDiscovery.startScan(HeosPlayerDiscovery.java:83)
        at org.openhab.binding.heos.internal.discovery.HeosPlayerDiscovery.scanForNewPlayers(HeosPlayerDiscovery.java:223)
        at org.openhab.binding.heos.internal.discovery.HeosPlayerDiscovery.playerChanged(HeosPlayerDiscovery.java:228)
        at java.base/java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:807)
        at org.openhab.binding.heos.internal.handler.HeosBridgeHandler.triggerPlayerDiscovery(HeosBridgeHandler.java:494)
        at org.openhab.binding.heos.internal.handler.HeosBridgeHandler.delayedInitialize(HeosBridgeHandler.java:168)
        at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at java.base/java.lang.Thread.run(Thread.java:834)

this happens every 2 hours for all my players and is glogging up my logfiles.

Hi @tsmit ,

I have the same issue and therefore I opened a Pull Reqeust to solve the issue.

The new version also adds support to use the Denon Home speakers as bridge.
You can download a testing version of the jar here: