Yamaha MusicCast binding revival

I turn off and on power of YAS408, and no more messages in log.
I can send commands, but no feedback from device.
Some logs if it helps:

2022-02-01 19:06:46.933 [INFO ] [cast.internal.YamahaMusiccastHandler] - YXC - Start Keep Alive UDP events (5 minutes - Yamaha Гостиная) 
2022-02-01 19:06:46.955 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 
java.lang.NullPointerException: null
	at org.openhab.binding.yamahamusiccast.internal.YamahaMusiccastHandler.fillOptionsForMCLink(YamahaMusiccastHandler.java:871) ~[?:?]
	at org.openhab.binding.yamahamusiccast.internal.YamahaMusiccastHandler.generalHousekeeping(YamahaMusiccastHandler.java:410) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:829) [?:?]

...
2022-02-01 21:09:57.895 [WARN ] [cast.internal.YamahaMusiccastHandler] - IO Exception - DeviceInfo - java.util.concurrent.ExecutionException: java.net.SocketTimeoutException: Connect Timeout

Looks like your device is not responding in time or at all.
The first lines in the log are functions which I created in the binding.
Does the app work?

Yes, Misiccast iOS App work.
Binding still can send commands, but not receive.
Restart binding from openhab console bring back binding to life.

But my second Yamaha, which did not turn off, continued to work normally with binding

I’m just switching from the old 0.79 to 0.84 and experiencing some issues with device linking. I try to link three devices as follows. However, they are not getting linked:

Linking:

Yamaha_Livingroom_Power.sendCommand(ON)
Yamaha_Kitchen_Power.sendCommand(ON)
Yamaha_Bedroom_Power.sendCommand(ON)
Yamaha_Livingroom_MCLinkStatus.sendCommand("server")
Yamaha_Kitchen_MCLinkStatus.sendCommand("client")
Yamaha_Bedroom_MCLinkStatus.sendCommand("client")
Thread::sleep(300)
Yamaha_Kitchen_MCLinkStatus.sendCommand("192.168.1.11***main")
Thread::sleep(300)
Yamaha_Bedroom_MCLinkStatus.sendCommand("192.168.1.11***main")

(192.168.1.11 = Yamaha_Livingroom_Power)

Unlinking:

Yamaha_Livingroom_MCLinkStatus.sendCommand("")
Yamaha_Kitchen_MCLinkStatus.sendCommand("")
Yamaha_Bedroom_MCLinkStatus.sendCommand("")

What am I doing wrong? To be honest, documentation on linking seems quite sparse. Maybe you could add a full example for linking and unlinking? It also doesn’t become apparent what the different linking commands do exactly as they seem ambiguous. For example, for what do I tell the server to be the server when this will be automatically done when a device connects?

1 Like

Right Things text config with no errors is:

Bridge yamahamusiccast:bridge:virtual "YXC Bridge" {
    Thing device Living "YXC Living" [host="1.2.3.4", defaultAfterMCLink="none", syncVolume=false]
}

Items:

Switch YamahaPower "YamahaPower" {channel="yamahamusiccast:device:virtual:Living:main#power"}
Switch YamahaMute  "YamahaMute " {channel="yamahamusiccast:device:virtual:Living:main#mute"}

Received a second musiccast device and trying to link those two, but without luck so far. Can anyone please share a working example?

I tried different rules but none of them worked. This was my last test:

sendCommand(Yamaha_Living_MCLinkStatus, "Server")
sendCommand(Yamaha_Kitchen_MCLinkStatus, "192.168.1.1***main")
sendCommand(Yamaha_Kitchen_Input, "mc_link")

192.168.1.1 is the IP from the Living Speaker. Is there anything wrong with that?

Any hint would be welcome. Thanks in advance.

Hello @cornhulio

I have this :

sendCommand(YamahaBadkamerMCLinkStatus, "192.168.1.150***main")

with “YamahaBadkamerMCLinkStatus” being the speaker I want to be the slave,
and “192.168.1.150” being the IP from the spaker I want to be the master.

Works perfect for me…

Thanks @CobleS … checked everything and found that I had an old version from the plugin.

Removed the od version and updated to latest version in OH3.3
But still using the syntax above something seems to not work.

Using this rule

	sendCommand(Yamaha_Kueche_MCLinkStatus, "192.168.178.93***main")

Checking my events.log I can see the the status switches back to client. Any idea why this can happen?

2022-04-29 21:53:59.965 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Yamaha_Kueche_MCLinkStatus' received command 192.168.178.93***main
2022-04-29 21:53:59.973 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Yamaha_Kueche_MCLinkStatus' predicted to become 192.168.178.93***main
2022-04-29 21:53:59.979 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Yamaha_Kueche_MCLinkStatus' changed from client to 192.168.178.93***main
2022-04-29 21:54:00.017 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Yamaha_Kueche_MCLinkStatus' changed from 192.168.178.93***main to client

My things look like this:

Bridge yamahamusiccast:bridge:bridge "Musiccast_Bridge" {
    //Thing yamahamusiccast:device:Musiccast20 "Musiccast20" [host="192.168.178.84" ]
    Thing device XDAQS5400_Kueche  "XDAQS5400 Kueche" [host="192.168.178.101", defaultAfterMCLink="none", syncVolume=false]
    Thing device XDAQS5400_Schlafen  "XDAQS5400 Schlafen" [host="192.168.178.93", defaultAfterMCLink="none", syncVolume=false]

Relevant Items should be those:

String Yamaha_Kueche_MCLinkStatus "" {channel="yamahamusiccast:device:bridge:XDAQS5400_Kueche:main#mclinkStatus"}

Hello together,

I installed the binding and have a WX-10 that I can control (volume, see the title, etc.).

How can I output a sound on a WX-10 using a rule? The sound file (eg MP3) should be on my Raspberry Pi (there is openHAB). This would be e.g. the possibility to realize a doorbell.

@cornhulio : could you try giving your bridge another name? If I remember correctly, using the word bridge as name, makes it not to work. In my setup I use yamahamusiccast:bridge:virtual
@Jeff_Smart : that is not supported. I plan on implementing that one day but live is too busy at the moment and this functionality is unknown territory for me.

@BeanzBE … thanks for your reply. I renamed the items and bridge and it was working once. After that I had the same behavior. Performed some further tests and I think another issue was the defaultAfterMCLink of none. As it seems that it stayed with the mc_link status and after that a second reconnect was not working.

So besides changing the bridge name from:

Bridge yamahamusiccast:bridge:bridge "Musiccast_Bridge"
to
Bridge yamahamusiccast:bridge:virtual "XDA Bridge"

I adjusted the defaultAfterMCLink from:
Thing device eg_Kueche_Musiccast_xda "Musiccast Kueche" [host="192.168.178.101", defaultAfterMCLink="none", syncVolume=false]
to
Thing device eg_Kueche_Musiccast_xda "Musiccast Kueche" [host="192.168.178.101", defaultAfterMCLink="net_radio", syncVolume=false]

Thanks for your help :slight_smile:

I have the exact same problem, after a while openhab (or after a restart of openhab) do not receive any update the receiver, so i change the bridge from yamahamusiccast:bridge:virtual to yamahamusiccast:bridge:virtua, after saving the file, i change back to yamahamusiccast:bridge:virtual and save it again. From this point it works.

Is that a bug?

Hi, i do restart of MusicCast binding every night, this help keeping binding work

I found a workaround for the lack of audio sink in this binding which I thought I should share. It’s actually very simple, I wish I’d found it years ago.

Musiccast devices are UPnP renderers, so simply install the UPnP Control Binding. The binding will detect the devices, and then you can use playSound in a DSL rule - all in the binding docs. I’ve been using this without issue for a few weeks.

I’ve not looked at how to set the speaker back to what it was playing before, but shouldn’t be too hard in a rule using store / restore states.

Thanks for all your work on this @BeanzBE - it’s my primary control for my speakers and been running pretty smoothly for me for a long while now.

4 Likes