Hi,
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
Hey,
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 
Something is wrong after getting correct albumart_url from getPlayInfo
2019-01-16 23:44:18.019 [DEBUG] - >> GET http://172.27.0.110/YamahaExtendedControl/v2/netusb/getPlayInfo
2019-01-16 23:44:18.025 [DEBUG] - JSON is {"response_code":0,"input":"qobuz","play_queue_type":"system","playback":"pause",
"repeat":"all","shuffle":"off","play_time":4,"total_time":325,"artist":"Efterklang",
"album":"Piramida","track":"Hollow Mountain","albumart_url":"/YamahaRemoteControl/AlbumART/AlbumART8603.jpg",
"albumart_id":8603,"usb_devicetype":"unknown","auto_stopped":false,"attribute":84148639,
"repeat_available":["off","one","all"],"shuffle_available":["off","on"]}
next weird stuff happens: (trying YamahaExtendedControl/v2 again)
2019-01-16 23:44:18.026 [DEBUG] - >> GET http://172.27.0.110/YamahaExtendedControl/v2
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
Chris
Hi,
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.
Hi,
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 http://172.27.0.110/YamahaRemoteControl/AlbumART/AlbumART8855.jpg
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 
(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 
Hi,
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 
Thanks
Hi Guys anyone working on this?? Would be great to have a link feature that the Music Cast app has to be able to link the music cast devices for whole home audio
If anyone wants to implement it Id happy to pay for it!
If anyone needs a workaround:
I am using Yamaha MusicCast Speakers as audio sinks with the SqueezeBox binding.
To get this working you have to install the Logitech Media Server (aka Squeeze Box).
Within Logitech Media Server Webinterface you are able to set up AirPlay Speakers as Audio Sinks.
From this point you can use the speakers within openhab via squeeze box binding.
Hi all,
I can’t manage to create the requrired jar file to be used in OpenHab 
Can someone help with the latest version? Looks smarter than the http integration
Regards
Joerg
Hi, I added the latest jar to the released in the github page. In that version I was playing with the code for playing a url on the speakers so be aware that it maybe not work as intended.
1 Like
Thanks a lot.
I‘m mostly interested in getting the things to power on/off and hopefully it returns status as well so I can use that in rules. Volume is also interesting even I managed to get this working using the http Binding already, incl visu Update, but I trust it’s much smarter with a dedicated Binding and thing.
The rest like input, playlist etc would be great to get this added, but currently it looks like all are working on different bindings 
This is no complain, as I know that there is business and other topics and obviously the MusicCast/Ipenhab Community is still few people and just few of them are programmers.
Thanks!!