Yamaha MusicCast binding revival

Continuing the discussion from Yamaha musiccast binding:

I adopted the MusicCast binding started by Frank Zimmer. In the current stage, power and volume can be retrieved and set. In the near future, I will add additional features like artwork, source, …

You can find the project here:

Kind regards!


Great stuff!

When I get some time I’ll be trying it with a YSP-2700, ISX-18D and the WX-030 which you already have.

That would be great. Currently, it’s a bit exploring: auto-discovery, power, volume, mute, album-art, … next step is adding zones, play controls, …
I hope you like it!

1 Like

Good news!
I already implement many items using the http binding and rules but having a binding should be better.
Keep going
I will test soon

Where can I find the jar file for this?

Thanks for reviving this binding, was looking for an excuse try building a binding. So here is my fork of your code. https://github.com/hrodz/yamaha/tree/refactor

I added code for an event receiver (adapted the code from the silvercrestwifisocket binding) to avoid polling the device for changes. Fixed the errors and some of the warnings for compiling the binding fro openhab. I’m no programmer and this is my first time coding in Java. I changed some of the code just for learning purposed.

1 Like


great! I wasn’t able to contribute much the last couple of weeks, but I hope to work further on it later this month. I gave your code a quick look and it seems fine. Thanks!

There is no jar yet, but I’m looking to add it to the eclipse jenkins server so build are done automatically.

1 Like

I’m very happy to see that there is progress on the binding again.
Great work !!!
I tested the binding and everything works very nice & smooth except the AlbumArt

Bad News: I can’t find the reason myself
Good News: I realized my debugging skillz :grinning:

Something is wrong after getting correct albumart_url from getPlayInfo

2019-01-16 23:44:18.019 [DEBUG] - >> GET
2019-01-16 23:44:18.025 [DEBUG] - JSON is {"response_code":0,"input":"qobuz","play_queue_type":"system","playback":"pause",
                                           "album":"Piramida","track":"Hollow Mountain","albumart_url":"/YamahaRemoteControl/AlbumART/AlbumART8603.jpg",

next weird stuff happens: (trying YamahaExtendedControl/v2 again)

2019-01-16 23:44:18.026 [DEBUG] - >> GET
2019-01-16 23:44:18.030 [DEBUG] - JSON is {"response_code":3}
2019-01-16 23:44:18.031 [DEBUG] - JsonObject: {"response_code":3}
2019-01-16 23:44:18.031 [DEBUG] - org.openhab.binding.yamahamusiccast.internal.api.MusicCastException: Invalid Request (A method did not exist, a method wasn’t appropriate etc.)

I also tried the “empty albumart_url” situation where it should take the 120x120.jpg --> with the same behaviour trying to parse the wrong url YamahaExtendedControl/v2

Would be great if there’s a solution (or is it me missing something?)
Thanks! regards


I don’t think I have change anything related to the album art, but it seems to be broken (at least on my fork). It is getting the information from the speaker but not presenting it in openhab. The call to YamahaExtendedControl/v2 is to keep the subscription alive to receive events from the speakers, it has always returns response code 3 in my testing. It is not related to the album art.

I’m currently not displaying the album art on my testing so I did not notice the problem. Maybe you can try Dries Decock to see if it is working (it was when I first tried it), this can help me know it is something with my modifications.

On a side note I have added a player (media control) channel and continued with some code refactoring, I hope to have some time this weekend to push the code to github.


I used your fixes to build Dries Decock’s Fork and there the AlbumArt is still working.
So it must be somewhere in your later modifications.
Could it be that because of the response code 3 and the following internal.api.MusicCastException: Invalid Request it “breaks apart”?

In Dries Decock the last part from the refresh request is the correct URL:

22:34:48.494 [INFO ] - Refreshed everything.
22:34:48.495 [DEBUG] - Getting image from

player channel (combined with Artist / Title / Album info) sounds realy nice - could be one of the last pieces to make it perfect
there would be only one thing I’m actually thinking of after that:
a quick selection of the favorites like it’s possible with the RC or the “Room Scenes” that you can create

I have a dream… that one day… when I wake up to my openhab alarm in the morning it’s OH that start’s the scene instead of me :smile:
(actually it’s working by script but the defineable “Room Scenes” are really nice feature

Thanks for testing, I found the bug for the album art image. It was a typo in the channel definition. I pushed the latest changes to github with preliminary player control, the fix for the album art and some work toward selecting and controlling different zones. Adding Artist / Title / Album info should be straight forward, will add those when I have sometime. After that I will explore adding the speakers as audio sinks. I haven’t deal with room scenes or room presets so I can not comment on that at this moment.

Edit: Added the latest compiled jar to github releases just in case anyone else wants to test it.

AlbumArt is working now with the disadvantage that auto-discovery can’t find the speaker anymore.
Not a big Deal but it was realy nice to get it automatically with Type and Name of the Device as a Thing.

I think Room Scenes can’t be done over the API - i guess all the information that build up a scene is stored only in the MusicCast App
but the presets are in the API Specification.

Audio Sink is a complete different topic compared to the API, no?

Yes, audio sync is not related to the API. Auto discovery was working for me, will double check to make sure. Anyway I have to see if there’s a way to modify existing things when adding new features (I remember reading somewhere it was possible). Right now we have to delete existing things and discover them again to get the new channels.

I just try the discovery and it seems to be working, I deleted one of the speakers and then press the scan in the inbox and it found the speaker. I don’t know if this is what you refer or is something different. Most of my devices use legacy bindings so I do not have a lot of experience with discovering things.

Yes, exactly the discovery (scan) function in the inbox.
With the actual version I can’t find my speaker anymore automatically by scanning.
But with the previous version (the one with the AlbumArt typo) I don’t even need to scan - after adding the binding my speaker came totaly automatic inside the inbox.
Would be great if somebody else could test too

Tested again removing all speakers and after restarting the binding all of them were discovered without the need of scanning manually. Agree that more testing is needed. Pushed the latest sources with channels for album, artist, track and album art url. These maybe a good reason for testing the discovery again :smiley:


I will try you fork and see if the discovery is working. Maybe we can merge the code again and divide some of the open features so this binding becomes useful for many people?

Sounds great. Let me know if you would want me to do a pull request with all the changes so you can review the code or if you want to discuss the changes before attempting any merging of the code. Thanks.

Edit: added preliminary support for audio sink. Discovered speakers are registered as audio sinks, I’m able to stream to the speakers sending the url to the playuri channel or with the playSound or playStream commands. Currently both sounds and streams are played through openHAB, for some reason I’m not able to play urls directly from the speakers.

1 Like

Hi All

Is there any documentation on the binding? Sample items file would be nice :slight_smile: