that sounds good! I did another change and now also the Bridge discovery should work again with openhab 2.2.0.
For switching ON and OFF the receiver unfortunately there is no command provided by Denon via the CLI. I think you have to use the Denon binding for that. I know that it is currently reworked to work with the new receivers again.
The new release of the binding will be attached below.
Yes I also noticed that. I´m working on it. If you want to get the binding started a workaround is to install the hue binding. After that the binding starts correctly.
Today I installed the Heos binding (to control my Denon AVR-X1400H). I must say the installation went pretty smooth. I really like the dynamic channels. It discovered my Heos Favorites!
I use this binding in combination with the new Denon/Marantz binding. I use the Denon-binding to power on/off my AVR and the Heos binding to start playing my webradio.
A have a question: I wanted to create a rule that switches on my Denon receiver, and starts to play my favorite radio station.
Switching on the Denon is done by the Denon/Marantz binding. That works fine.
Then I assumed I just had to switch on my Favorite (defined via the dynamic channel) and send a “PLAY” command.
However, it just starts to play the last music I selected, instead of that favorite.
I guess I miss a step. I can switch on the Favorite-item. However, I haven’t defined which player it should start playing (even though I only have one in my Denon ecosystem).
Yes you missed a step. You have to select the player channel you want to play your favorites on first and then select the favorite channel. Then the favorite starts automatically. You do not need a play command in addition.
The binding does not check if only one player is available on the network.
I think I should add an example on the readme to clarify this.
I just add latest bindig.heos-2.3 RC1.3 to my OH2 on PI and no bindings in PaperUI, in log I see:
2018-01-14 23:09:41.122 [ERROR] [org.openhab.binding.heos ] - FrameworkEvent ERROR - org.openhab.binding.heos
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.heos [211]
Unresolved requirement: Import-Package: org.eclipse.jdt.annotation; resolution:="optional"
Unresolved requirement: Import-Package: org.eclipse.smarthome.config.discovery.upnp
at org.eclipse.osgi.container.Module.start(Module.java:444) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1620) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1600) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1571) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1514) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) [?:?]
@grzegorz914
Hi,
This is a known issue. And to be honest I don’t know where the problem is.
As a workaround you can install the hue binding and then also the HEOS binding starts. It seems that the hue binding is able to load the required components.
@Serrrano
I haven’t tried it. But it shouldn’t be no problem.
The way I would do it is creating a new item which I would map to a HomeKit item (switchable) and give it the name you want.
I think you need a rule to map the specific inputs to an HEOS action.
Wire82
@Wire82
Just used your binding in my Openhab setup. Works great until now, thank you!.
As I’m currently too stubborn to use openhabian / paperui and have to do many things by hand I also ran into this issue. The solution/work-around I found online https://community.openhab.org/t/creating-a-binding-with-upnp-discovery/37839 is the following.
It seems that as long as bindings are placed in the addon folder and are not fully merged with the Openhab database, dependencies are not automatically installed.
By opening the karaf console and adding the dependency (UPNP) yourself it works. Command to do so is: feature:install esh-io-transport-upnp
Unfortunately each user to do a clean install has to do so (unless other bindings are installed that already have this dependency installed, like HUE). I did not find any other ways to have it installed automatically.
It seems that, until the binding gets fully included in the openhab installation, people will be bound by using either this karaf method or installing other UPNP-dependent bindings.
Bart
Thank you for that input. I thought the same. So currently the way you do it would be the right way until the binding is merged into the OpenHab branch.
Is it possible to explain how PlayUrl works ?
For instance, use one of the Player to play a sound (a MP3 somewhere on the LAN, accessible through HTTP, let’s say http://mysoundserver/welcome.mp3) when an item state changes (with a rule).
Hi,
I’m testing this binding since december and It works nearly perfectly.
I just can notice that playing a sound from console (smarthome:audio play doorbell.mp3 for example) doesn’t work.
Even when the heos speaker is configured as default sink in system>audio (PaperUI) and callback URL defined as localhost in binding.
Altought the same config works for sonos speakers.
Any idea?
Regards.
sorry for the long time without any new release and information about the state of the binding. It was some kind of time issue…
But today I released a new version with several improvements and new features. The details are described within the release notes.
The binding can be downloaded here:
Unfortunately I was not able to merge the binding to the latest release 2.3.0 of OpenHab. But I promises I will do my best to get it merged into the official OpenHab version as fast as possible.
So please feel free to give feedback about the binding and possible issues or ideas.
