The code is in this branch in my repo.
https://github.com/jarlebh/openhab2-addons/tree/heos?files=1.
Thanks! I had a first look on the source code and it seems that controlling different playback zones for multiroom audio systems is currently extremely hard to achieve with the Eclipse SmartHome API. For me it feels like an additional item type is needed to have a proper solution for these kind of problems. This also applies to the Sonos Binding - the current approach includes a bunch of switches and strings which seems to be quite awful and not very user-friendly.
@maintainers: I searched within the last 30 minutes for running discussions about how to improve the Eclipse SmartHome API regarding those challenges, but did not find anything. Do I miss something? Whatās your opinion, does it make sense to open a seperate thread for this topic and discuss this or are there already running activities / discussions on the API that have the goal to improve this situation?
What kind of support do you expect there? Not sure if I get your requirement/question.
For now, the question just was if thereās already something on the roadmap or ongoing discussions somewhere else about Eclipse SmartHome API improvements that could may help in realizing multiroom system bindings. If the answer is no Iād spent some thoughts about it during christmas holidays and come up with a seperate discussion thread with some ideas in 2017.
Or, if you think the current API is completely sufficient for this use case, how could a clean solution look like according to your opinion?
Well, it currently works. But it is a bit cumbersome. Not sure exactly how to improve it, this binding is based on the SONOS binding 
Sorry for another newb question. How do I get this addon working?
I downlaoded the jar file posted in November in this thread and copied it to my openhab2 addons directory. Now I am a bit lost since this is the first time I am using a addon which did not come with Openhab2 already included. Shouldnāt I be able to see it within paper UI Addons now?
NoTechi
@NoTechi: I would describe the development state of this addon as pre-alpha and not ready for use by non-developers. Quite a lot stuff is not implemented or hard to use (like grouping rooms). I think jarlebh (or maybe me if he has no time and needs support) will add a user-friendly documentation later on.
@jarlebh: Maybe, if you have some time within the next days / weeks it would be very nice to have short overview whatās implemented / tested by you. I also miss an overview what exactly is already working and whatās missing / what are the open issues (a few days ago I tested the AUX IN switch and recognized that the method is not implemented yetā¦).
Regarding possible ESH improvements or improvement of the whole concept of the Sonos and Heos binding, I also still have no clear concept / proposal. But when it comes to control the interesting parts like grouping of the speakers, I think itās a little bit more than just āa bit cumbersomeā 
Basically, you cannot use it without reading the API documentation by Denon, executing telnet commands to find out the UIDs of your speakers and implementing complex rules. Implementation that should be done by the binding and not by the userā¦
I am fine with a pre-alpha and take the risk that its not perfect ;). Just being able to start the last (and only) favorite (itās a TuneIn radio station) in my alarm clock routine to have some nice wake up music in the morning next to the lights going on would fulfill all my needs
NoTechi
Hello,
I found that topic a few days ago. Maybe a little late for me but okay.
I also have started to develop a Heos binding for OpenHab. Itās in a very early state and Iām not a professional programmer so I think there are many thinks which has to be improved. But if you want check my binding.
Currently the binding discover the Heos Player as a bridge. After adding one of the player as a bridge the binding searches the Heos network for available players and add them to the inbox. There they can be added and controled.
Again, itās a very early state and hopefully I have time to improve the binding.
1 Like
@NoTechi and @pfink: I improved the binding over the last days. Heos Groups are supported know and they are removed automatically if the group is ungroup. Also from an external source.
For me the biinding seems to work well. Maybe some one can try and give me a short feedback 
Wire82
That sounds promising and I would love to test it! But I will need a short install guide for dummies since so far I just used bindings which came with openhab2 already. From what I have read to add other bindings I need the tar file and it goes in the addons folder. So my first question would be how to get the tar file? 
Do I need some sort of config files or thats all todo and I have the heos player discovered as bridge in my Inbox and I can proceed as you described above?
Really appreciate your assistance and sharing your binding
NoTechi
Okay. I will try to compile the binding tomorrow. To be honest, I havenāt tried it outside of the development environment.
I will send a short notice here if itās done.
I am ready to be the pre alpha beta tester!
NoTechi
@NoTechi: You can find a .jar file of the binding here:
Itās release V.0.1.0
You have to add the .jar into the addons folder of your Openhab 2.
Then the players should be discoverd. Add one of them as a Bridge (Naming should start with āATC-ā. After that the players and groups of the system will be discovered and you can add them. If you add a group (via the App at the moment) it will shown in the Inbox.
Please make sure that you have enabled āItem Linknā under āConfiguration/Systemā. If not no channels are linked and you do not see the controls and you have to add them manualy
Within the next release I will change the bridge discovering so that only one Player is schown as bridge.
So feel free to comment the bindingā¦
Wire82
Worked like a charm! I did not test it beside installing and playing from controls in paperui but thats great already!
Not that I would really need it but others might be interested in picking stored favorites like radio stations. Do you think that would be possible as well?
You made me very happy now I can include the Heos in my wake up and coming home routine many thanks for sharing your work! 
NoTechi
Yes that shouldnāt be a problem. (Hope soā¦) I have some ideas how to do that and Iām working on it.
I think it will take a little bit longer because I donāt have time to work on it this week. But I will write you if itās implemented.
Hi Wire82, this is exactly what I was looking for. Have the Heos connection over Telnet commands and exec binding solved. But Iām not happy.
Now I wanted to test this jar. After the installaton in the openhab2/addons I get now this error message.
[org.openhab.binding.heos ] - FrameworkEvent ERROR - org.openhab.binding.heos
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.heos [221]
Bundle was not resolved because of a uses contraint violation.
org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource org.openhab.binding.heos [osgi.identity; osgi.identity=āorg.openhab.binding.heosā; type=āosgi.bundleā; version:Version=ā0.1.0.-SNAPSHOTā; singleton:=ātrueā] because it is exposed to package ājavax.annotationā from resources org.eclipse.osgi [osgi.identity; osgi.identity=āorg.eclipse.osgiā; type=āosgi.bundleā; version:Version=ā3.10.101.v20150820-1432ā; singleton:=ātrueā] and javax.annotation-api [osgi.identity; osgi.identity=ājavax.annotation-apiā; type=āosgi.bundleā; version:Version=ā1.2.0ā] via two dependency chains.
Chain 1:
org.openhab.binding.heos [osgi.identity; osgi.identity=āorg.openhab.binding.heosā; type=āosgi.bundleā; version:Version=ā0.1.0.-SNAPSHOTā; singleton:=ātrueā]
require: (osgi.wiring.bundle=org.eclipse.osgi)
|
provide: osgi.wiring.bundle: [org.eclipse.osgi, system.bundle]
org.eclipse.osgi [osgi.identity; osgi.identity=āorg.eclipse.osgiā; type=āosgi.bundleā; version:Version=ā3.10.101.v20150820-1432ā; singleton:=ātrueā]
Chain 2:
org.openhab.binding.heos [osgi.identity; osgi.identity=āorg.openhab.binding.heosā; type=āosgi.bundleā; version:Version=ā0.1.0.-SNAPSHOTā; singleton:=ātrueā]
import: (osgi.wiring.package=com.google.common.collect)
|
export: osgi.wiring.package=com.google.common.collect; uses:=javax.annotation
com.google.guava [osgi.identity; osgi.identity=ācom.google.guavaā; type=āosgi.bundleā; version:Version=ā18.0.0ā]
import: (osgi.wiring.package=javax.annotation)
|
export: osgi.wiring.package: javax.annotation
javax.annotation-api [osgi.identity; osgi.identity=ājavax.annotation-apiā; type=āosgi.bundleā; version:Version=ā1.2.0ā]
at org.eclipse.osgi.container.Module.start(Module.java:434)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1562)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
Can you help me?
Hi Wire82,
no hurry I really appreciate you are working on this!
It looks like I got a problem keeping the Heos Thing initialized after openhab restart. I get the status:
āInitializingā on the Heos bridge under Things and
"UNINITIALIZED - HANDLER_MISSING_ERROR"
in my heos group item within paper UI e.g. after I restarted openhab.
And this is the log file entry:
2017-01-09 23:16:39.107 [WARN ] [ome.core.thing.internal.ThingManager] - Initializing handler for thing āheos:Bridge:f4970b92-4b1a-fd8e-2ce7-01c5594d02b4ā takes more than 5000ms.
I can start everything without problem via the Heos app.
Any ideas?
NoTechi
@NoTechi. Yes I know that this can happen. I guess I know where the problem is and I will work on it. I think this can be solved in reorganizing the starting procedure. I keep that in mind.
@tanrickson
Hmm that looks like some libraries are not loaded correctly. But I donāt know that the problem is. . Do you have the latest openhab version?
@NoTechi. You donāt get that message. Right?