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?
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:
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?
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]
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.
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.
After last Yamaha update i see this warns in logs:
2022-12-26 16:45:26.261 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler YamahaMusiccastHandler of thing yamahamusiccast:device:b:room tried accessing its bridge although the handler was already disposed.
2022-12-26 16:45:26.274 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler YamahaMusiccastHandler of thing yamahamusiccast:device:b:room tried checking if channel main#mclinkStatus is linked although the handler was already disposed.
2022-12-26 16:45:26.284 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler YamahaMusiccastHandler of thing yamahamusiccast:device:b:room tried updating channel main#mclinkStatus although the handler was already disposed.
