Yamaha MusicCast binding revival

Add-ons Bindings
61

@joedirt thx for the feedback. This shows I’m going in the right direction.
Are you missing something? Except for zone support for which I must do some research.

The latest version works on OH 2.5.5 and 2.5.8 (I did an upgrade in the meantime)
Developed on JAVA8 but running on JAVA11 on my linux distro.
Tested with an RX-D485 (2 devices) and a WXA-50 . Currently testing on a WX-010.

So things to do

  • Support multiple zones
  • Support MusicCast Link
  • Prepare for OH3 and hopefully have it added to the addons
2 Likes
62

Awesome work, yea multiple zones with the linking feature zones feature (party mode) in the yamaha binding.

63

Handling commands is now supporting zones however that version is not yet available. There are only 4 in the API documentation so it’s not getting too complicated.
Now working on the refresh process to support the 4 zones.
The zones are also needed for linking so needed to start with that.

64

that’s awesome and your progress is fantastic. im happy to help with beta builds if you want feedback.

65

New version with zone support available on Github
Only tested with my RX-D485 with main zone. However, the player/playback controls are part of a separate zone and this works as well, I’m kinda convinced it will work :innocent:

Thanks for testing, looking forward to the feedback.
Please mention what model you’re using, always good to mention in the README

(Will start verifying musiccast link)

66

How good! I’ve only just seen the update (didn’t get an email saying there was a new post) ill test it out tonight and report back.

67

Good job mate!!!

So after testing this latest update I can confirm that the 2nd zone on my receiver turns on and off, volume control works and so does the player controls but only if the main zone has the same source playing. if the source is different then the main zone is the one that the player controls effect.

There is a slight delay between the 2 zones if they are playing the same source. (my workaround for this is a rule that automatically turns on party mode in the Yamaha receiver binding if the sources are the same) and my avr is the RX-A860

68

Have you had a chance to make any progress with MusicCast link yet?

69

OK, let me see if I can find something there

Not sure how to tackle this one

Thanks for the info

Not really. Trying to figure out what the concept would be within the OpenHAB framework.
Any idea/suggestion is highly appreciated.

Studied the API which is clear to me.

70

My ideal would be adding “linked zones” for each physical zone in the source selection dropdown list. Mine would look look something like “Spotify, Apple TV, Nintendo Switch, Linked Zone 1, Linked Zone 2…” the linked zones would be acting as virtual zones. The linked zones would have their source selection dropdown list to select a source to play on all linked zones. So in my case I would have “Spotify, Apple TV and Nintendo Switch” as my available selections for each linked zone.

So if I wanted to play Spotify in the study, kitchen and outside I would select from the dropdown source selection for each of the zones linked zone 1. For the source select dropdown for linked zone 1 i would select Spotify.

71

I was already thinking to have a dedicated channel for musiccast, but your addition might be the thing I was missing. How many virtual zones would you need then?

P.S. : I only get the notification by mail if it is a reply.

73

3 would be awesome. ok sweet, noted.

74

Thanks for this contribution Lennert, it’s very useful. I’ve used the power / volume / mute / select preset functions successfully across my WX-010, WX-030, ISX-80 and YSP-1600 :+1:.

What’s not working is the binding reflecting the status of the thing’s channels when they’re changed from outside of OpenHAB, e.g. via physical buttons or the app on a device (volume/mute/on off state). I’ve tried toggling refresh after action without success, although not sure what the refresh is exactly meant to do.

Thinking about the link mode, as you suggest it’s kind of hard to model in OpenHAB, and having taken a glance at the documentation it doesn’t look like a simple thing to implement. That said, I wonder if one option might be to present a ThingAction, where users could then specify a list of things which they wish to link. They’d then need to know which device was primary in the linked group and control that. Alternatively maybe a channel on the thing which takes the id of a device to stream from? You could also take a glance at how the Sonos binding works, considering Sonos have similar functionality, but it might be implemented very differently.

A few ideas for future development (happy to help if I can - is this your latest work?):
To make it easier to configure the devices I wonder if discovery could be implemented. Considering the existing yamaha binding detects but can’t control musiccast devices some code could be cribbed from that.
You could dynamically make channels available from inspecting a devices features - e.g. zones 2-4 don’t apply to any of the devices I own.
My ISX-80 has sleep and alarm functionality which I’d love to control from OpenHAB.

75

So far power/volume/mute/presets work fine for everybody who tested the binding.

The refresh interval will run every x seconds to reflect the status of the device. So if an action is done outside OpenHAB, it will be reflected in OH after x seconds.

Toggling refresh after action runs the refresh command directly after launching an action in OH, eg pressing a button. However, I noticed this caused delays. It is still there for testing but might remove it.

I’m open for all feedback but still haven’t made up my mind regarding the link mode. However, I already looked at the Sonos binding. Will have another look.

The repo on Github is mine but was a first try, so please ignore it.
If all works well, I will look for Discovery.
Also will look at alarm and sleep. If it is basic functionality, it can be easily added.

76

I’m really excited to see what you come up with. I’ve just added 2 more MusicCast amps to my house the r-n303d and the ex-a1080 both working perfectly with the implemented functional

77

Hi Lennert, Thanks for the explanation.

I can confirm that the status updates in the UI are working on each refresh for my YSP-1600, but not the other devices. With logging on, each update simply reports YXC - Nothing to do! - ISX-80 (main). Looking at your code I’d wager it’s because my WX and ISX devices don’t report sound_program in getStatus, but if you could share a link to the latest code I can confirm this.

Other than this the plugin is great, I’ve been hunting for a reliable Windows app to control my devices and it turns out the solution was under my nose in OpenHAB.

Regards,

James

78

Hi @jamesmelville, @joedirt ,

updated list of things to do :slight_smile:

  • Save code in a repo so it is accessible for everyone. This will also allow for issue tracking
  • Prepare for OH3: Currently this is all written for OH 2.5.5 with JAVA8. OH3 is on it’s way with JAVA11. I’m waiting for that to have it uploaded and apply to be part of offical addons. In the meantime, option 1 should help everybody
  • Sleep is easy to add, will try to add it in the coming days.
  • What is the JSON response for getStatus for ISX-80? (That function hasn’t changed much so you might be right)
  • Trying to fit it MusicCast in a channel. Need to play around with some options. First try will be for Main zone only anyway.
  • Updating README with tested devices, thanks to you guys.
79

Uploaded code to GitHub :heavy_check_mark:

80

Thanks! The responses from my WX and ISX devices are all the same structure:

{
    "response_code":0,
    "power":"standby",
    "sleep":0,
    "volume":15,
    "mute":false,
    "max_volume":60,
    "input":"tuner",
    "distribution_enable":true,
    "equalizer": {
        "mode":"manual",
        "low":0,
        "mid":0,
        "high":0
    },
    "link_control":"standard",
    "link_audio_quality":"compressed",
    "disable_flags":0
}

I’d recommend you fork the openhab-addons repository, then create a branch in your repository and add the code there, it’ll make things a lot easier when it comes to trying to merge it into the core app. You could tag a release against a commit and upload the jar file to github to make it available.

At risk of teaching you to suck eggs:

Updating the code for openhab 3 is fairly easy, flipping your dev environment over might be a little harder but I assume you’ve already seen the instructions here. Might be worth sticking with building for 2.5.x for the moment and delaying the pain whilst we’re all still actively using that.

Make sure you’ve reviewed the developer guidelines, an obvious example in the existing code is how you’ve implemented logging which will need changing before the code is accepted. I’d also use GSON and DTOs to deserialise the JSON responses.

81

Thanks for all feedback, still learning.

I’ve seen the instructions for OH3. Like you suggested, my plan currently is to stick with 2.5.x.
We are all on 2.5.x so everyone can benefit from the changes. The pain to upgrade will be postponed till most functionality is available.
At the same time I will review the code to start using DTO and respect the coding guidelines.
For now it is OK.

Regarding the JSON : I will look into DTO.
Regarding Sleep function : on my shortlist
Regarding the Music Cast link : working on some designs on paper to see where it goes

1 Like